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METHODS AND APPARATUS FOR MANAGING AN 
5 APPLICATION ACCORDING TO AN APPLICATION 

LIFECYCLE 

Background of the Invention 
1 . field of the invention 

10 The present invention relates generally to computer software. More 

particularly, the present invention relates to methods and apparatus for managing 
execution of an application. In addition, the present invention relates to methods and 
apparatus for implementing an application lifecycle design for software applications. 



15 2. DESCRIPTION OF RELATED ART 

The digital television revolution is one of the most significant events in the 
history of broadcast television. With the advent of digital television, high speed data 
transfer is possible via satellite, cable and terrestrial television channels. Digital 
television offers users more channels as well as significantly improved video and 

20 audio quality. Most importantly, digital television ushers in the age of true interactive 
television. For instance, digital receivers will be able to offer users a variety of 
enhanced services, fi-om simple interactive quiz shows, to internet, and a mix of 
television and web-type content. As the market for digital television grows, content 
developers are looking for a feature-rich, cost-effective, and reliable software 

25 platform upon which to build the next generation of interactive television services 
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such as Electronic Programming Guides, Video-On-Demand, and Enhanced 
Broadcasting. 

Java is a leading commercial object-oriented language designed as a portable 
language that can run on any compatible device that supports the JAVA™ 
5 PLATFORM. For instance, Java is incorporated into all major Web browsers. Thus, 
Java runs on any web-enabled computer via that computer's Web browser. As such, 
Java offers great promise as the software platform for set-top boxes and digital 
television. 

In object-oriented programming, code and data are merged into objects. Each 
10 object is defined via its class, which determines the properties and behavior of an 
object. In other words, objects are individual instances of a class. 

In the desktop environment, certain resources associated with each loaded 
application (e.g., classes and objects) need not be frequently released or tightly 
monitored since memory is relatively unlimited. However, memory is a valuable 
15 resource in the environment of embedded systems, particularly in the area of digital 
television. Moreover, in an interactive digital television environment, it will be 
common to run multiple applications. A digital television service might consist of 
audio, video and one or more applications. For instance, when a television viewer 
changes the channel, each associated service or program provided by that channel will 
20 likely require that multiple classes be loaded. As a result, memory will continually be 
allocated to the applications and associated classes until the limited amount of 
memory is consimied. Once the memory is consumed, it will be impossible to run 
any ftirther applications. This is particularly important since it will be undesirable to 
reboot the set-top box in the event of an error. 
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The JAVA PLATFORM currently defines a number of application models, 
each with its own lifecycle. In general, these application lifecycle models have been 
designed to address specific issues on the JAVA PLATFORM. For instance, the 
Applet was designed to provide support for executable content in web pages. 
5 However, none of the existing apphcation lifecycle models fully address the 

requirements specific to systems having limited memory, such as television receivers. 
For instance, classes associated with an Applet, once loaded, its class objects will not 
be removed from memory. Moreover, it is impossible to determine when execution 
of the Applet has been terminated. 
10 In view of the above, it would be beneficial if an application lifecycle were 

designed to address the requirements specific to television receivers. Moreover, it 
would be desirable if a mechanism for managing the loading and execution of an 
application according to an application lifecycle were designed. 



15 SUMMARY 

The present invention enables one or more applications to be managed. In 
addition, execution of one or more applications may be managed according to an 
application lifecycle. This is accompHshed, in part, through the use of an application 
manager that is capable of initiating and monitoring changes in the state of the 
20 apphcation. In this manner, applications may be executed in a consistent manner on a 
variety of platforms. 
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According to one aspect of the invention, an application manager loads the 
application and allocates resources to the application for use by the application 
throughout its execution. Once the application is loaded, the application manager 
executes the application according to an application lifecycle. This is accomplished 
5 according to one embodiment through an application interface that is visible to the 
application manager. Through this application interface, the application manager can 
initiate various state changes in the application. As one example, the application 
manager may request the application to pause its execution and enter a paused state. 
As another example, the application manager may request the application to continue 
10 its execution from the paused state and enter an active state. 

According to another aspect of the invention, the application communicates 
information regarding its state and potential state changes to an application manager. 
According to one embodiment, this is accomplished, in part, through an application 
environment interface. Through this application environment interface, the 

1 5 application may request that the application manager cause a state change of the 

application. For example, the application may request that the application manager 
cause the application to enter the active state. In addition, the application may 
indicate through this application environment interface that the application cannot 
perform the service as requested and therefore has paused or terminated, as 

20 appropriate under the circumstances. Once the state of the application is changed 
(e.g., caused by the application manager or performed by the application), the 
application may communicate this state change to the application manager (e.g., 
through an application environment interface that is visible to the application). 
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According to yet another aspect of the invention, the apphcation manager may 
terminate the apphcation on a conditional or unconditional basis. When the 
application manager terminates the application unconditionally, the application must 
terminate. However, when the application manager terminates the application on a 
5 conditional basis, the application manager may terminate the application only when 
the application agrees to its termination. Li this manner, the application manager may 
terminate applications and therefore release resources associated with applications in 
a manner that is agreed upon by the applications being terminated. 

The present invention enables applications to be managed according to an 
10 application lifecycle by an application manager. This enables applications to be 
executed in a predictable manner regardless of the platform on which they are 
executed. Moreover, since the application manager monitors the current state of each 
of the apphcations, the application manager may release memory associated with each 
application immediately upon its termination. This is particularly useful in systems 
15 having limited memory, such as in a digital television receiver. 



Brief Description of the Drawings 

The invention, together with further advantages thereof, may best be 
understood by reference to the following description taken in conjunction with the 
20 accompanying drawings in which: 

FIG. 1 is a block diagram illustrating a digital television receiver in which the 
present invention may be implemented. 
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FIG. 2A is a block diagram illustrating one embodiment of the invention in 
which an application manager is implemented to manage applications that are loaded 
via the digital television receiver. 

FIG. 2B is a diagram presenting an exemplary set of rules according to which 
5 the application manager shown in FIG. 2A may operate. 

FIG. 3 is a block diagram illustrating an exemplary data structure which is 
used to store signal data received by the application manager as shown in FIG. 2A. 

FIG. 4A is a diagram illustrating an exemplary context list that is accessed by 
the application manager during management and execution of associated applications. 
10 FIG. 4B is a diagram illustrating an exemplary data structure used to store an 

application context identified in the exemplary context list. 

FIG. 5A is a block diagram illustrating an exemplary list of display contexts 
accessed by a display manager according to one embodiment of the invention. 

FIG. 5B is an exemplary state diagram associated with a display context. 
15 FIG. 5C is a diagram illustrating a set of exemplary display states generated 

according to a set of exemplary rules followed by the application manager. 

FIG. 6 is a state diagram illustrating a set of states which an application may 
enter during the lifecycle of the application. 

FIG. 7 is a diagram illustrating an exemplary application interface identifying 
20 methods that may be called by an application manager during the lifecycle of an 
application. 

FIG. 8 is a diagram illustrating an exemplary application environment 
interface identifying methods that may be called by an application during the lifecycle 
of an application. 
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FIG. 9 is a diagram illustrating methods that may be called by either the 
application manager or an application during the lifecycle of the application. 

FIG. 10 is a process flow diagram illustrating one method of implementing an 
application manager to load an application and execute the apphcation according to 
5 an application lifecycle according to an embodiment of the invention. 

FIG. 1 1 is a process flow diagram illustrating one method of loading an 
application as shown at block 1022 of FIG. 10. 

FIG. 12 is a process flow diagram illustrating one method of executing an 
application according to an apphcation lifecycle as shown at block 1024 of FIG. 10. 
10 FIG. 13 is a process flow diagram illustrating one method of changing the 

state of an application from loaded to paused as shown at block 1206 of FIG. 12. 

FIG. 14 is a process flow diagram illustrating one method of changing the 
state of an application from paused to active as shown at block 1208 of FIG. 12. 

FIG. 15 is a block diagram illustrating a typical, general-purpose computer 
15 system suitable for implementing the present invention. 

Detailed Description of the Preferred 
Embodiments 

In the following description, numerous specific details are set forth in order to 
20 provide a thorough understanding of the present invention. It will be apparent, 

however, to one skilled in the art, that the present invention may be practiced without 
some or all of these specific details. In other instances, well known process steps 
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have not been described in detail in order not to unnecessarily obscure the present 
invention. 



An invention is described herein that enables an application to be loaded and 
executed according to an application lifecycle. The sequence of steps by which an 
5 application becomes initialized, makes various state changes based on its 

environment, and eventually is destroyed is collectively known as the application 
lifecycle. According to one embodiment, this is accomplished through the use of an 
application manager that is capable of loading and managing execution of one or 
more applications. According to one embodiment, the application lifecycle is 

10 implemented through the use of two interfaces. First, an application programming 
interface enables the application manager to manage the execution of an application 
according to the application lifecycle. Second, an application environment interface 
enables the application to communicate to the application manager its desire to 
change from one state to another or, alternatively, indicate that it is unable to perform 

15 a state change as requested by the application manager. For example, an application 
may request that the application manager cause the application to enter an active state. 
As another example, the application may indicate that it has entered a paused state or 
a destroyed state (e.g., when it is unable to enter the active state as requested by the 
application manager). Thus, the application environment interface may enable the 

20 application communicate to the application manager that it has changed from one 
state to another since the application ultimately has the best knowledge of the state 
that it is in. 

The invention is described within the context of a digital television and digital 
television receiver. FIG. 1 is a block diagram illustrating an exemplary digital 
25 television receiver. As shown, a signal is received via antenna 102 and tuned by tuner 
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module 104, producing MPEG2 transport stream 106. De-multiplexer 108 then 
produces encrypted MPEG streams 110 including a video stream 1 12, an audio stream 
114, and a data stream 116. These three streams are then processed by conditional 
access subsystem 118. For instance, the conditional access subsystem 118 may utilize 
5 key management information 120 as well as decryption information 122 (e.g., 

decryption algorithms). The conditional access subsystem 118 produces decrypted 
MPEG streams 123 including a video stream 124 and audio stream 125 as well as 
data 126, all of which are decrypted. A decoder 128 then processes the decrypted 
MPEG stream 123, and forwards the decoded video data to frame buffer 130 and 

10 transmits the decoded audio data to speaker 132. 

A Java Virtual Machine is one platform that may be used to implement the 
present invention to process information received by a digital television receiver such 
as that illustrated in FIG. 1. More particularly, when the data 126 (e.g., broadcast data 
stream) is processed, it is desirable to process information such as a downloaded 

1 5 application provided in the data 126. 

FIG. 2 A is a block diagram illustrating one embodiment of the invention in 
which an application manager is implemented to manage applications that are loaded 
via the digital television receiver. As shown in FIG. 2 A, the present invention may be 
implemented in a digital television receiver 200. A broadcast data stream 202 is 

20 received by a signaling monitor 204. The signaling monitor 204 determines whether 
an application is present in the broadcast data stream 202 and provides signal data 206 
indicating the presence or absence of an application as well as data associated with 
the application such as the location of the application. The application manager 208 
then loads and executes the application using this signal data 206. For instance, the 

25 application manager 208 may execute the application according to the appropriate 
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application lifecycle so that the appUcation enters the appropriate states in response to 
specific conditions. One implementation of the application lifecycle design will be 
described in further detail below. As the application executes, display information is 
provided in the form of a display context 210 from a display manager 212. The 
5 display manager then provides the appropriate display information for display on a 
television monitor 214. 

According to one embodiment of the invention, the application manager is 
configured to operate according to a set of rules 216. These rules may be specified in 
a variety of ways in order to implement an application lifecycle. For instance, an 

10 application lifecycle may enable an application to enter a loaded state, a paused state, 
an active state, and a destroyed state upon the occurrence of predetermined events. 
FIG. 2B is a diagram presenting an exemplary set of rules according to which the 
application manager shown in FIG. 2 A may operate. This exemplary set of rules 216 
includes four rules. A first rule 218 specifies that the application manager manages 

15 one or more applications. However, a second rule 220 specifies that only one 

application can be active (i.e., execute) at any given point in time. Moreover, a third 
mle 222 specifies that only one application can be displayed at any given point in 
time. Finally, a fourth mle 224 specifies that only active applications are displayed. 
Thus, a set of rules may be designed and configured for an application manager in a 

20 variety of ways. Accordingly, the set of mles may be designed to manage execution 
of one or more appUcations according to an application lifecycle. 

FIG. 3 is a block diagram illustrating an exemplary data structure which is 
used to store signal data received by the application manager as shovm in FIG. 2 A. 
Signal data 302 includes an application present indication 304 in the broadcast data 

25 stream. If an application is present, a location 306 of that file (e.g., directory and file 
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name) is specified. In addition, information such as authentication infomiation 308 
enabling the originator of the appUcation to be authenticated as well as permissions 
310 indicating that a particular action (e.g., read/write) can or cannot be performed in 
association with a specified source and/or destination. 
5 The application manager 208 may simultaneously manage the lifecycle of 

numerous applications. According to one embodiment of the invention, in order to 
maintain information associated with each potentially executing application 400, the 
application manager manages an application context list 402. FIG. 4 A is a diagram 
illustrating an exemplary application context list 402 that is accessed by the 

10 application manager 208 during management and execution of associated applications 
400. As shown, the application context list 402 includes one or more entries, where 
each entry identifies an application context 404 that is associated with one of the 
applications 400. More particularly, applications 400-A, 400-B, 400-C, and 400-D 
represent four potentially different applications, with different application contexts 

15 404- A, 404-B, 404-C, and 404-D, respectively. The application context 404 identifies 
information associated with an application to enable the application to be loaded as 
well as executed according to an application lifecycle. 

According to one embodiment, information associated with an application is 
centralized and referenced by the application context 404. FIG. 4B is a diagram 

20 illustrating an exemplary data structure used to store an application context 404 
identified in the exemplary application context list 402 presented in FIG. 4A. The 
exemplary data structure for the application context 404 includes a class loader 
identifier 406 that identifies a class loader, an object used to load classes into 
memory. Thus, the class loader identifier 406 enables the application manager to load 

25 one or more classes associated with the application via the identified class loader as 

11 
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well as unload these classes by de-referencing the class loader. In addition, the 
exemplary data structure for the application context 404 includes a signal data 
identifier 408 that identifies the signal data 302 as shown in FIG. 3. Thus, the 
application manager 208 may use this signal data identifier 408 to determine the 
5 location of an application as well as authentication and permission data. The 

exemplary data structure for the application context 404 further includes a display 
context identifier 410 that identifies a display context including information that will 
be used by the display manager 212 shown in FIG. 2 A to display the application. For 
instance, the display context may include a reference to an object that allows the 

10 display of an application on a screen, such as the size, position, and visibility data. 
The exemplary data structure for the application context 404 fiirther includes an 
application identifier 412 identifying the apphcation. In addition, an application 
environment object 414 is identified that enables the application to communicate with 
the application manager. As one example, the application may wish to communicate 

15 its desire to enter another state or enter another state and communicate this state 

change to the application manager (e.g., commxmicate that it has entered the paused or 
destroyed state). As another example, the application may wish to obtain information 
related to the application environment (e.g., as maintained in the associated 
application context). The application environment object 414 will be described in 

20 fiirther detail with reference to FIG. 8 and FIG. 9. The exemplary data structure for 
the application context 404 is fiirther shown to identify the current application state 
416. Thus, the application manager 208 maintains a record of the application state of 
each application. 

As described above with reference to FIG. 2 A, a separate display manager 212 
25 may be implemented to manage access to the display device, as well as manage the 

12 
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data that is ultimately displayed. To facilitate this process, the display manager 
maintains a list of display contexts according to one embodiment of the invention. 
FIG. 5 A is a block diagram illustrating an exemplary list of display contexts (display 
context list) 502 accessed by a display manager according to one embodiment of the 
5 invention. As shown, the display context list 502 includes one or more entries 
associated with one or more applications 400- A through 400-D. Each entry in the 
display context list 502 is associated with a context identifier 504 and identifies a 
display context 506 specifying information related to an application's display. In 
other words, the display context may be aa object that holds the information needed 

10 by an apphcation to display itself Thus, when the display manager 212 wishes to 
display an application, it may "turn on" the appropriate "window" referenced in the 
corresponding display context, possibly by turning others off. 

The display context may be displayed according to a state diagram for the 
display context. FIG. 5B is an exemplary state diagram associated with a display 

15 context. As shown, the display context is visible 508 when in a first display state and 
invisible 510 when in a second display state. The appropriate display state is 
determined, according to one embodiment, by the rules followed by the application 
manager. 

FIG. 5C is a diagram illustrating a table presenting a set of exemplary display 
20 states generated according to a set of exemplary rules followed by the application 
manager, as shown and described above with reference to FIG. 2B. Table 512 
illustrates all possible display states 514 and their associated application states 516. 
According to the exemplary set of rules followed by the application manager, only 
active applications are displayed. Thus, when an application is in the active state, the 
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display state is visible. Alternatively, when an application is in the paused state, the 
display state is invisible. 

An application lifecycle is implemented by enabling an application to enter a 
number of states under predetermined conditions. The states, as well as the 
5 conditions that deteraiine when an application will enter each of the states, may vary 
according to the implementation of the application manager and the application 
lifecycle. FIG. 6 is a state diagram illustrating a set of states which an application 
may enter during the lifecycle of the application according to one embodiment of the 
invention. When the application manager loads the application, the application enters 

10 the loaded state 602. Once the application enters the loaded state 602, the application 
may enter the paused state 604 after its initialization by the application manager. 
Only the application manager can cause the application to change its state to the 
active state 606 from the paused state 604. However, either the application manager 
or the appUcation may cause the application to enter the paused state 604 from the 

15 active state 606. Li addition, either the application manager or the application can 
cause the application to terminate and enter the destroyed state 608 from the loaded 
state 602, the active state 606, or the paused state 604. 

As described above with reference to FIG. 6, the state of the application may 
be changed by the executing application or an appUcation other than the executing 

20 application (e.g., the application manager). In many object-oriented languages, 
methods and variables may be grouped into modules so that method names and 
parameters are visible to external processes (e.g., through an interface) while 
implementation details are hidden from those external processes. According to one 
embodiment, the interfaces and associated methods that are accessible to the 

25 application and the application manager are "packaged" into what will hereinafter be 
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referred to as packages. Each package includes an associated interface that defines 
those methods names and parameters that are externally visible. In addition, each 
package has an associated body that includes the bodies, and therefore the 
implementation details, of the methods defined in the interface of the package. The 
5 application and application manager may use the two different interfaces to 

communicate. Thus, the application manager and the application can alter the state of 
the application through the use of two different interfaces, an application interface and 
an application environment interface, respectively. In addition, the application 
manager and the application can communicate information such as information 

10 regarding state changes or potential state changes. 

FIG. 7 is a diagram illustrating an exemplary application interface identifying 
methods that may be called by an application manager (or other process) during the 
lifecycle of an application to change the state of the application. An application 
interface 702 defines all methods and associated parameters that may be called by the 

15 application manager. An initialize method 704 is available to enable the application 
manager to initialize the application. For instance, the initialize method 704 may 
signal the application to initialize itself and enter the paused state fi*om the loaded 
state. According to one embodiment, a parameter of the initialize method 704 is an 
application environment object 706, which will be described in further detail below 

20 with reference to FIG. 8. The application environment object 706 may also be used 
by the application to access properties associated with the application's runtime 
environment, as will be described below. In addition, through the use of the 
application environment object 706, the application may retrieve the properties 
associated with its runtime environment. For instance, properties that may be 

25 retrieved include a reference to the signaling data and a reference to the environment 
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the service is presented from (e.g., audio/video environment). In this manner, the 
application may initiahze itself in preparation for its execution. Although the 
appUcation preferably does not hold shared resources prior to executing, it should be 
prepared to execute in a reasonable amoimt of time. The initialize method 704 should 
only be called once. After the initialize method 704 retums successfully, the 
application is in the paused state. If the initialize method 704 cannot retum 
successfully, the application retums a state change exception indicating that the 
application cannot enter the paused state. 

Once the application is in the paused state, the application may enter the active 
state. However, only the appUcation manager can cause this state change using a start 
method 708. The start method 708, once called, signals the application to start 
providing service and enter the active state. In the active state, the application may 
hold shared resources. A variety of failures may prevent the service from starting. 
For instance, the failure may be transient or non-transient. According to one 
embodiment, the application distinguishes between these two types of failures. For 
transient failures, a state change exception is raised. When a non-transient failure 
occurs, another exception may be raised or a done method may be called to properly 
terminate the method. For example, when the application determines that it cannot 
access the resources it needs to execute, this may be implemented as either a transient 
or non-transient failure. 

A pause method 710, once called by the application manager, signals the 
application to stop executing and enter the paused state from the active state. In the 
paused state, the application stops executing and tries to use as few resources as 
possible. Thus, the application may release a portion or all of the shared resources 
held by it. 

16 
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It may be desirable to terminate the application from any one of the loaded, 
active, or paused states. This may be accomplished by calling a destroy method 712. 
The destroy method 712 signals the application to terminate and enter the destroyed 
state. In the destroyed state, the application should release all resources and save 
5 preferences or state information. 

When the application manager wishes to destroy (e.g., terminate) an 
application, it may be desirable to indicate various levels of urgency. According to 
one embodiment, the termination of an application is performed when a 
predetermined condition is satisfied. As one example, the predetermined condition 

1 0 may be the presence of a signal from the application agreeing to its premature 

termination. As another example, the predetermined condition may be the lack of 
receipt of a signal from the application within a specified period of time. This may be 
accomplished through a parameter 714 to the destroy method 712. The parameter 714 
indicates that the destroy signal is conditional when in a first state and unconditional 

15 when in a second state. Thus, when the application manager merely wishes to request 
that the application terminate, it may specify that the destroy signal is conditional 
upon the application's decision to terminate. The application may indicate that it 
wishes to continue to execute and therefore not enter the destroyed state by raising a 
state change exception. If the application manager wishes to honor this request from 

20 the application, the application manager may call the destroy method again at a later 
time. Altematively, the application manager may attempt to destroy another 
application that has, for example, a higher (or lower) priority. In this manner, the 
application manager may obtain resources needed by it (e.g., by the next application 
to be loaded) from only those applications which choose to terminate. Moreover, the 

25 application manager may attempt to destroy the applications in a specified order, such 
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as a priority order, the application using the most (or least) amount of memory, or 
order in which execution has been initiated. 

When the application manager needs a specific application to terminate, it 
may indicate this by specifying that the destroy signal is unconditional through the 
5 parameter 714 of the destroy method 712. For instance, the application manager may 
specify that the destroy signal is unconditional when all resources held by the 
application are needed by the application manager. Thus, the application manager 
may force an application to terminate and release resources held by it when the 
destroy signal is unconditional. Accordingly, even if an application raises a state 

10 change exception indicating that it wishes to continue to execute, the application 
manager may ignore this exception when the destroy signal is unconditional. 
Although the above-description refers to the conditional and unconditional 
termination of an application, other operations may similarly be performed 
conditionally and unconditionally. 

15 As described above, an application environment object is passed to an 

application when the application is initialized. Li addition, the application 
environment object provides an application with a mechanism to retrieve properties, 
as well as a way to signal internal state changes. According to one embodiment, the 
application environment object has an application environment interface that is 

20 available to the application being loaded and executed. More particularly, once the 
application is initialized, the application environment interface is available to the 
application. 

FIG. 8 is a diagram illustrating an exemplary application environment 
interface identifying methods that may be called by an executing application during 
25 the lifecycle of the application. As will be shown and described below, an application 
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environment interface 802 provides several methods allowing an application to 
discover information about its environment as well as communicate with the 
application manager regarding its state changes and desired state changes. 

As described above, the application may enter the destroyed state from the 
5 loaded, active, or paused states. Moreover, the application manager or the application 
may cause the application to enter the destroyed state. As shown and described with 
reference to FIG. 7, the application manager may destroy the application by calling 
the destroy method. Alternatively, a destroyed method 804 of the application 
environment interface 802 enables the application to signal that it has entered itself 

10 into the destroyed state. The appHcation manager then updates the application state to 
destroyed without calling the destroy method provided in the application interface, as 
described above with reference to FIG. 7. The application performs the same 
operations (e.g., clean up, releasing of resources) as if the apphcation was destroyed 
by the application manager. This is preferably performed before the application 

15 enters itself into the destroyed state. 

When the apphcation is in the active state, the application manager or the 
application may cause the application to enter the paused state. More particularly, the 
application manager may pause the application using the pause method, as shown and 
described with reference to FIG. 7. Alternatively, the application may signal that the 

20 application does not want to be active and has entered the paused state via paused 
method 806. 

A get property method 808 having a parameter 810 provides an application 
with a mechanism to retrieve one or more properties from the application 
environment object. As one example, in a Java environment, a "root container" is 
25 typically used to contain user interface components (e.g., pull-down menus, buttons) 
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SO that they can be displayed in the Java environment. Thus, the get property method 
808 may be used to determine the root container in which components can be placed. 
As another example, information associated with the broadcast data stream (e.g., 
location of file within the broadcast data stream) may be obtained. Other properties 
5 may include, for example, a reference to a service session object (service context) and 
information specific to the underlying transport protocol. 

Although only the application manager can cause an application to enter the 
active state, the application may wish to indicate that it is interested in entering the 
active state. This is accomplished, according to one embodiment, via a resume 

10 request method 812. Through the resume request method 812, one or more 

applications may each indicate a desire to enter the active state. However, the number 
of applications that may be simultaneously executed may be limited by the set of mles 
that the application manager follows. For instance, as described above with reference 
to FIG. 2B, the rules may specify that only one application can be active at a time. 

1 5 Thus, calls to the resume request method 812 may be used by an application manager 
to determine those applications that wish to enter the active state so that the 
application manager may select one or more of the requesting applications to move to 
the active state. 

Through the above described interfaces, the application lifecycle can be 
20 controlled by both the application manager and the application. Although the 

interfaces are well-defined, the bodies of the methods shown and described above 
with reference to FIG. 7 and FIG. 8 may be implemented in a variety of ways, so long 
as the associated interface (and associated state machine) is complied with. 

FIG. 9 is a diagram illustrating exemplary methods that may be called by 
25 either the application manager or an application during the lifecycle of the 

20 
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application. As shown in FIG. 9, separate sets of methods may be called by the 
application manager 902 and each application 904 managed by the application 
manager 902. As previously described with reference to FIG. 7, a first set of methods 
may be called by the application manager 902, including an initiaUze method 906, a 
5 start method 908, a destroy method 910, and a pause method 912. Similarly, as 

previously described with reference to FIG. 8, a second set of methods may be called 
by a corresponding appHcation 904, including a paused method 914, a destroyed 
method 916, a resume request method 918, and a get property method 920. 

FIG. 10 is a process flow diagram illustrating one method of implementing an 

10 application manager to load an application and execute the application in accordance 
with an application lifecycle according to an embodiment of the invention. The 
process begins at block 1002 and at block 1004 the digital television receiver is tumed 
on. The Java environment is then started at block 1006. An application manager is 
then constructed at block 1008 to manage the loading and execution of one or more 

15 applications. The application manager is then run at block 1010. 

A variety of digital television services may be received by a digital television 
receiver such as that illustrated in FIG. 1 . In addition to receiving a multitude of 
channels (or services), these services could range from interactive television, to near 
video-on-demand, to specialized programming. More particularly, a service provided 

20 by a television channel will often include audio, video, and an application. When a 
service is selected (e.g., by a user switching channels) at block 1012, a data stream 
associated with the selected service is received via the digital television receiver at 
block 1014. For instance, when the user switches to the Disney channel, the Disney 
service is selected and a data stream associated with the Disney service is received. 
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At block 1016 it is determined whether an application associated with the 
selected service is present in the data stream. For instance, when the user selects the 
Disney service, a Disney application may be received in the data stream. If it is 
determined that an application is present in the data stream at block 1018, the 
5 application manager loads the application as shown at block 1022 and executes the 
application according to the application lifecycle at block 1024. The loading and 
executing processes will be described in further detail below with reference to FIG. 1 1 
and FIG. 12, respectively. The process completes as shown at block 1026. If there is 
no application present in the data stream, the process returns to 1020 to wait for new 

1 0 signals related to an application to be present in the data stream received at block 
1014. The process then continues at block 1016. 

FIG. 1 1 is a process flow diagram illustrating one method of loading an 
application as shown at block 1022 of FIG. 10. The process begins at block 1 102. At 
block 1 104, signal data such as that illustrated in FIG. 3 is received by the application 

15 manager at block 1 104. Once the signal data is received, the application manager can 
locate and load the application. In order to store information associated with the 
application, an application context such as that illustrated in FIG. 4B is created at 
block 1 106. The application context may then be used to maintain a reference to all 
information associated with the application. For instance, once the application 

20 manager creates a class loader for the application as shown at block 1 108, a reference 
to the class loader may be maintained in the application context. Classes associated 
with the application are then loaded via the class loader at block 1110. An instance of 
the application is then created from the classes at block 1112. 

Once the application is instantiated, the application enters the loaded state as 

25 shown at block 1114. In order to enable the application to obtain properties 
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associated with its environment and communicate with the apphcation manager, an 
appUcation environment object complying with an application environment interface 
such as that illustrated in FIG. 8 is instantiated at block 1116. The application 
environment object is then initialized for the application when the initialize method is 
5 called by the application manager at block 1118. 

In addition to loading the application, the application manager is responsible 
for monitoring and managing the execution of the application. FIG. 12 is a process 
flow diagram illustrating one method of executing an application according to an 
application lifecycle as shown at block 1024 of FIG. 10. Through the use of 

10 interfaces such as those illustrated in FIG. 7 and FIG. 8, the application and the 

application manager can propose, delay, prevent, or effect a change in the state of the 
application. The following is a simplified description of the manner in which the 
state of the application is changed throughout the lifecycle of the application. The 
process begins at block 1202. Once the application has entered the loaded state, the 

15 application waits at block 1204 for the application manager to change the application 
state to paused. For instance, as described above, the application manager may 
initialize the application using the initialize method provided in the application 
interface, causing the application to enter the paused state as shown at block 1206, as 
will be described in further detail with reference to FIG. 13. Once the application is 

20 changed to the paused state, the application manager thereafter eventually changes the 
application state to active at block 1208 (e.g., using the start method), as will be 
shown and described in further detail with reference to FIG. 14. It is important to 
note that only the application manager can cause an application to enter the active 
state. From the active state, either the application or the application manager can 

25 cause the application to enter the paused state at block 1210 through the paused 
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method available in the application environment interface or the pause method 
available in the application interface, respectively. Once paused, the application may 
request that execution be resumed through the resume request method available in the 
application environment interface. The application or the application manager can 
5 also cause the application to terminate and enter the destroyed state at block 1212 via 
the destroyed method available in the application environment interface or the destroy 
method available in the application interface, respectively. As shown, the application 
may enter the destroyed state at block 1212 from any one of the loaded, paused, or 
active states. For instance, when the application completes execution, the application 

10 may enter the destroyed state. In addition, initiation of an action such as the loading, 
starting, or terminating of an apphcation may be initiated in response to a signal 
received by the television receiver. This may occur, for example, when a new 
program begins or a user presses a button on the television's remote control to select a 
new channel. Once an application changes its state as requested (e.g., method retums 

15 as appropriate), the application manager updates the current state of the application in 
the associated application context, as shown in FIG. 4A and FIG. 4B. Although not 
described with reference to FIG. 12, the above state changes are performed in 
compliance with any state change exceptions raised by the application. Thus, in most 
instances, when a state change exception is raised by the application, the application 

20 manager does not update the current state of the application. Instead, it may attempt 
to later request the same state change, another state change, or request a state change 
of another application. 

Once destroyed, resources held by the application may be released. For 
instance, a signal may be received by the application manager (e.g., from the 

25 application or the broadcast environment via the receiver) to initiate clean-up of the 
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application. More particularly, the class loader may unload the classes associated 
with the application at block 1214. In addition, the application context referenced by 
the application context list as shown in FIG. 4A and FIG. 4B may be released. 

As described above, the application manager changes the state of an 
application from loaded to paused in order to prepare it for execution. FIG. 13 is a 
process flow diagram illustrating one method of changing the state of an application 
from loaded to paused as shown at block 1206 of FIG. 12. The process begins at 
block 1302. At block 1304, the application manager calls the initialize method in the 
application interface and passes the application environment object as the parameter. 
The appHcation then uses the application environment object to initialize itself at 
block 1306. For instance, the application environment object may obtain properties 
such as the root container that it might use as it is initializing itself Thereafter, the 
application enters the paused state as shown at block 1308. 

According to one embodiment, only the application manager can change the 
state of the application to the active state. FIG. 14 is a process flow diagram 
illustrating one method of changing the state of an appUcation from paused to active 
as shown at block 1208 of FIG. 12. The process begins at block 1402. At block 
1404, the application receives a signal to start the application. For instance, such a 
start signal may be received by the application manager when a new program begins 
or when a user presses a button on the television's remote control. For some services, 
the applications may auto-start when they are tuned. The application manager then 
calls the start application method as provided in the application interface as shown at 
block 1406. The application performs its service and enters the active state at block 
1408. 
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The present invention may be applied in a variety of situations. One example 
is that of a stock ticker that is displayed at the bottom of a monitor (e.g., television 
screen) on various chaimels. The stock information may be obtained by a receiver 
from a broadcast service or a back channel to a central server or broadcaster (e.g., via 
5 modem, cable, or other connection to the Internet). Assuming that the stock ticker 
application is in the paused state after initialization, a user presses a button on the 
television's remote that signals the application manager to start the stock ticker 
application. The application manager calls the start application method for the stock 
ticker application. The application manager assumes at this point that the application 

10 is performing its service. Upon receiving the start signal, the stock ticker application 
creates a new thread that opens the back channel to retrieve the stock quotes. The 
stock ticker application is now in the active state. 

While in the active state, the stock ticker application continues to show the 
stock quotes. However, due to circumstances beyond the control of the application, 

15 the stock ticker application may no longer be able to retrieve updated stock quotes. 
Under these circumstances, the application may decide to continue displaying the 
most recent stock quotes that it has available. However, after a period of time, the 
application may still be unable to open the back channel. The application may 
therefore decide that the quotes it is displaying are too old to present and that it can no 

20 longer perform its service. The application may then choose to take itself out of the 
active state by calling the paused method on the application environment object to 
signal this change to the application manager. Moreover, the application may at this 
point or at a later time decide that it no longer has any chance of performing its 
service, so it decides it should terminate. The application does some clean-up, 

25 releasing resources that are no longer required by the application. The application 
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then terminates and calls the destroyed method on the application environment object 
to signal the application manager that it has entered the destroyed state. The 
application manager then does the corresponding clean-up of this application. 

The present invention may be implemented on any suitable computer system. 
5 FIG. 15 illustrates a typical, general-purpose computer system 1502 suitable for 
implementing the present invention. The computer system may take any suitable 
form. For example, the computer system may be integrated with a digital television 
receiver or set top box. 

Computer system 1530 or, more specifically, CPUs 1532, maybe arranged to 
10 support a virtual machine, as will be appreciated by those skilled in the art. The 
computer system 1502 includes any number of processors 1504 (also referred to as 
central processing units, or CPUs) that may be coupled to memory devices including 
primary storage device 1506 (typically a read only memory, or ROM) and primary 
storage device 1508 (typically a random access memory, or RAM). As is well known 
15 in the art, ROM acts to transfer data and instructions uni-directionally to the CPUs 

1504, while RAM is used typically to transfer data and instructions in a bi-directional 
manner. Both the primary storage devices 1506, 1508 may include any suitable 
computer-readable media. The CPUs 1504 may generally include any number of 
processors. 

20 A secondary storage medium 1510, which is typically a mass memory device, 

may also be coupled bi-directionally to CPUs 1504 and provides additional data 
storage capacity. The mass memory device 1510 is a computer-readable medium that 
may be used to store programs including computer code, data, and the like. Typically, 
the mass memory device 15 10 is a storage medium such as a hard disk which is 

25 generally slower than primary storage devices 1506, 1508. 
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The CPUs 1504 may also be coupled to one or more input/output devices 
1512 that may include, but are not limited to, devices such as video monitors, track 
balls, mice, keyboards, microphones, touch-sensitive displays, transducer card 
readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting 
5 recognizers, or other well-known input devices such as, of course, other computers. 
Finally, the CPUs 1504 optionally may be coupled to a computer or 
telecommunications network, eg., an intemet network or an intranet network, using a 
network connection as shown generally at 1514. With such a network connection, it 
is contemplated that the CPUs 1504 might receive information from the network, or 

10 might output information to the network in the course of performing the above- 
described method steps. Such information, which is often represented as a sequence 
of instructions to be executed using the CPUs 1504, may be received from and 
outputted to the network, for example, in the form of a computer data signal 
embodied in a carrier wave. 

15 Through the use of an application manager to load and manage execution of 

each application according to an application lifecycle, the execution of an application 
is standardized and memory resources are effectively conserved. The application 
lifecycle is implemented, in part, by controlling in a consistent manner the states that 
the application may enter. According to one embodiment, an interface defining 

20 appropriate methods for controlling the application lifecycle is provided for the 

application as well as the appHcation manager. In this manner, the application and the 
application manager may commxmicate state changes, requests for state changes, 
requests that state changes be delayed or cancelled, as well as communicate other 
state information. Through the use of the present invention, an application may be 

25 run on different machines at different times, yet producing the same result in a 
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predictable manner. Moreover, the present invention enables memory associated with 
an application to be released when it is determined that the resources are no longer 
required. Given the limited amount of memory resources in digital receivers and set- 
top boxes, the ability to manage memory resources in a digital television environment 
5 represents a significant improvement. 

Although illustrative embodiments and applications of this invention are 
shown and described herein, many variations and modifications are possible which 
remain within the concept, scope, and spirit of the invention, and these variations 
would become clear to those of ordinary skill in the art after perusal of this 

10 application. For instance, the present invention is described as being implemented 
within the context of a digital television receiver. However, the present invention 
may be used in other contexts. Moreover, although the present invention is described 
as being implemented on a JAVA PLATFORM, it may also be implemented on a 
variety of platforms. Moreover, the above described process blocks are illustrative 

15 only. Therefore, the implementation of the application manager and application 
lifecycle may be performed using altemate process blocks as well as alternate data 
structures. Moreover, although both the application manager and the application are 
described as having separate interfaces, these interfaces may include public methods 
that are visible to all applications as well as the application manager. Accordingly, 

20 the present embodiments are to be considered as illustrative and not restrictive, and 
the invention is not to be limited to the details given herein, but may be modified 
within the scope and equivalents of the appended claims. 
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Claims 

What is claimed is: 
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5 

L A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 

a computer-readable medium storing computer-readable instructions thereon, 
the computer-readable instructions including: 
10 instructions for receiving a state change request from an application, the state 

change request indicating a request from the application that an application manager 
initiate a change in state of the application from a first state to a second state; and 

instructions for initiating the state change of the application in response to the 
state change request when the second state is an allowable state according to a 
1 5 specified set of rules. 

2. The computer program product as recited in claim 1, wherein the second state 
is an active state indicating that the application is currently executing. 

20 3. A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 

a computer-readable medium storing computer-readable instructions thereon, 
the computer-readable instructions including: 

instructions for receiving a signal indicating that a new service is selected; 
25 instructions for initiating execution of the application when the new service is 

selected such that the application enters an active state; 

instructions for pausing execution of the application such that the application 
enters a paused state from the active state; 

instructions for receiving a resume request indicating that the application 
30 wishes to resume execution and enter the active state from the paused state; and 

instructions for starting execution of the application such that the application 
enters the active state from the paused state when the resume request is received from 
the application. 
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4. A computer program product for managing execution of a plurality of 
applications according to an application lifecycle, the computer program product 
comprising: 

5 a computer-readable medium storing computer-readable instructions thereon, 

the computer-readable instructions including: 

instructions for initiating execution of each one of the plvirality of applications 
such that the plurality of applications enter an active state; 

instructions for pausing execution of one of the plurality of applications such 
10 that the one of the plurality of applications enters a paused state from the active state; 

instructions for receiving a resume request from one or more of the plurality of 
applications indicating that the one or more of the plurality of applications request to 
resume execution and enter the active state from the paused state; 

instructions for selecting one of the one or more of the plurality of applications 
15 to move from the paused state to the active state; and 

starting execution of the selected application such that the selected application 
enters the active state from the paused state when the resume request is received from 
the application. 

20 5. A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 

a computer-readable medium storing computer-readable instructions thereon, 
the computer-readable instructions including: 

instructions for requesting a first time that an application change its state from 
a first state to a second state; 

instructions for determining whether the application has changed its state from 
the first state to the second state; and 

instructions for requesting a second time that the application change its state 
from the first state to the second state when it is determined that the application has 
not changed its state from the first state to the second state and a predetermined 
condition is satisfied. 
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6. The computer program product as recited in claim 5, wherein the 
predetermined condition indicates that a specified period of time has elapsed or that 
the apphcation is now able to perform the requested state change. 

5 7. The computer program product as recited in claim 5, wherein it is determined 
that the application has not changed its state when a state change exception is raised 
by the application. 

8. The computer program product as recited in claim 5, wherein it is determined 
10 that the application has not changed its state when the application rejects the 

requested state change. 

9. The computer program product as recited in claim 5, wherein it is determined 
that the application has not changed its state when the application is unable to perform 

1 5 the requested state change. 

10. A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 

a computer-readable medium storing computer-readable instructions thereon, 
20 the computer-readable instructions including: 

instructions for requesting that an application change its state firom a first state 
to a second state; 

instructions for detemiining whether the application has changed its state from 
the first state to the second state; and 
25 instructions for requesting that the application change its state from the first 

state to a third state when it is determined that the application has not changed its 
state from the first state to the second state. 

1 1 . The computer program product as recited in claim 10, wherein the first state is 
30 an active state indicating that the application is currently executing, the second state is 

a destroyed state indicating that the execution of the application has terminated, and 
the third state is a paused state indicating that execution of the application has paused 
such that the application can resume execution. 
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12. The computer program product as recited in claim 10, wherein it is determined 
that the application has not changed its state when a state change exception is raised 
by the application. 

5 13. The computer program product as recited in claim 10, wherein it is determined 
that the application has not changed its state when the application rejects the 
requested state change. 

14. The computer program product as recited in claim 10, wherein it is determined 
10 that the application has not changed its state when the application is unable to perform 

the requested state change. 

15. A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 

15 a computer-readable medium storing computer-readable instructions thereon, 

the computer-readable instructions including: 

instructions for requesting that a first application change its state from a first 
state to a second state; 

instructions for determining whether the first application has changed its state 
20 from the first state to the second state; and 

instructions for requesting that a second application change its state from the 
first state to the second state when it is determined that the first application has not 
changed its state from the first state to the second state. 

25 16. The computer program product as recited in claim 15, wherein the first state is 
an active, paused, or loaded state and the second state is a destroyed state indicating 
that the application is terminated. 

17. The computer program product as recited in claim 15, wherein it is determined 
30 that the first application has not changed its state when a state change exception is 
raised by the first application. 
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18. The computer program product as recited in claim 17, wherein the second 
state is an active state indicating that the associated apphcation is being executed, and 
the state change exception is raised by the first apphcation when the first apphcation 
has entered itself into a paused state or a terminated state. 

5 

19. The computer program product as recited in claim 15, wherein it is determined 
that the first application has not changed its state when the first application rejects the 
requested state change. 

10 20. The computer program product as recited in claim 15, wherein it is determined 
that the first application has not changed its state when the first application is unable 
to perform the requested state change. 

21 . A system for managing execution of an application according to an application 
15 lifecycle, the system comprising: 

one or more rules; and 

an application manager capable of executing one or more applications 
according to an application lifecycle enabling each of the applications to enter one of 
a plurality of states in response to one or more associated predetermined commands, 
20 the application manager capable of selecting one of the predetermined conmiands to 
execute according to the one or more rules. 

22. The system as recited in claim 21, further comprising: 

a signaling monitor coupled to the application manager and capable of 
25 receiving a data stream, the signal monitor adapted for determining whether an 

application is present in the data stream and communicating information associated 
with the application to the application manager. 

23. The system as recited in claim 21, wherein the application manager is 

30 configured to store an application context for each of the applications, the application 
context identifying a current one of the plurality of states. 
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24. The system as recited in claim 23, wherein the current one of the plurality of 
states is identified by the associated application to the application manager. 



25. The system as recited in claim 23, wherein the application context further 
5 identifies a class loader capable of loading one or more classes associated with the 

application. 

26. The system as recited in claim 23, wherein the application context further 
identifies a display context including display information to be displayed. 

10 

27. The system as recited in claim 23, wherein the application context further 
identifies an application environment object enabling the associated application to 
communicate with the application manager. 

15 28. The system as recited in claim 23, wherein the application context further 

identifies an application environment object that enables the associated application to 
retrieve properties associated with its runtime environment. 

29. The system as recited in claim 23, wherein the application context further 

20 identifies an application environment object that enables the associated application to 
communicate a state change to one of the plurality of states. 

30. The system as recited in claim 23, wherein the application context further 
identifies an application environment object that enables the associated application to 

25 request that the application manager change the current state of the application fi-om a 
paused state to an active state. 

31. The system as recited in claim 21, further comprising: 

a display manager coupled to the application manager and adapted for 
30 managing a display context for each of the applications, the display context being in a 
first state when the display context is visible and being in a second state when the 
display context is invisible. 
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32. The system as recited in claim 31, wherein the display context is in the first 
state when the associated application is in an active state and in the second state when 
the associated application is in a paused state. 



5 33. The system as recited in claim 31, wherein the state of the display context is 
determined according to the one or more mles followed by the application manager. 

34. A digital television receiver for managing execution of an application 
according to an application lifecycle, comprising: 
10 a processor; and 

a memory storing computer-readable instructions thereon, the computer- 
readable instructions including: 

instructions for determining from a data stream whether an application is 
present in the data stream; 
15 instructions for loading the application when it is determined that the 

application is present in the data stream; and 

instructions for executing the application according to an application lifecycle 
including a plurality of states. 

20 35. The digital television receiver as recited in claim 34, wherein the instmctions 
for executing the application comprise: 

a first interface that is visible to an application manager, the first interface 
adapted for enabling the application manager to cause the application to change fi*om 
one of the plurality of states to another one of the plurality of states; and 

25 a second interface that is visible to the application, the second interface 

adapted for enabling the application to communicate to the application manager a 
state change of the application fi-om a first set of the plurality of states to a second set 
of the plurality of states. 

30 36. The digital television receiver as recited in claim 35, wherein the second set of 
the plurality of states includes a paused state indicating that the application has been 
paused and a destroyed state indicating that the application has been terminated. 
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37. The digital television receiver as recited in claim 34, wherein the instructions 
for executing the application comprise: 

a first interface that is visible to an application manager, the first interface 
adapted for enabling the application manager to cause the application to change its 
5 state from one of the plurality of states to another one of the plurality of states; and 
a second interface that is visible to the application, the second interface 
adapted for enabling the application to request that the application manager change 
the state of the application to a first one of the plurality of states. 

10 38. The digital television receiver as recited in claim 37, further comprising: 

instructions for changing the state of the application from a second one of the 
plurality of states to the first one of the plurality of states. 

39. The digital television receiver as recited in claim 38, wherein the first state is 
15 an active state and the second state is a paused state. 

40. The digital television receiver as recited in claim 34, wherein the instructions 
for executing the application comprise: 

a first interface that is visible to an application manager, the first interface 
20 adapted for enabling the application manager to cause the application to change its 
state from one of the plurality of states to another one of the plurality of states; and 

a second interface that is visible to the application, the second interface 
adapted for enabling the application to communicate to the application manager that 
the application cannot change its state as the application manager has requested. 



25 



30 



41 . The digital television receiver as recited in claim 40, further comprising: 
instructions enabling the application to raise a state change exception 

indicating that the application cannot change its state as the application manager has 
requested. 

42. The digital television receiver as recited in claim 40, further comprising: 
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instructions enabling the application to raise a state change exception 
indicating that the application does not want to change its state as the application 
manager has requested. 

5 43. The digital television receiver as recited in claim 36, further comprising: 

instructions for releasing memory associated with the application when the 
application has been terminated. 



44. The digital television receiver as recited in claim 34, further comprising: 
10 instructions for creating a class loader associated with the application, the 

class loader being adapted for loading one or more classes associated with the 
application; 

instructions for employing the class loader to load the classes associated with 
the application; and 

15 instructions for instantiating the application using the classes that have been 

loaded by the class loader. 



45. The digital television receiver as recited in claim 44, further comprising: 
instructions for unloading the classes associated with the application when the 

20 application is terminated. 

46. The digital television receiver as recited in claim 45, wherein the instmctions 
for unloading the classes comprise: 

instructions for de-referencing the class loader. 

25 

47. A state machine for an application manager that manages execution of an 
application in a digital television receiver environment, said state machine 
comprising: 

a loaded state in which the application has been loaded; 
30 a paused state in which the application is paused, the application being 

initialized to transition from said loaded state to said paused state; 

an active state in which the application is executing, the application being 
started to transition from said paused state to said active state; and 
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a destroyed state in which the application is destroyed, the appUcation being 
terminated to transition from either said active state or said paused state to said 
destroyed state. 

5 48. A state machine as recited in claim 47, wherein the application can transition 
from said loaded state to said destroyed state when the application is to be terminated 
while in said loaded state. 

49. A state machine as recited in claim 48, wherein either of the application 
10 manager or the application can initiate the transition to said destroyed state. 

50. A state machine as recited in claim 47, wherein the application can transition 
from said active state to said paused state when the application is to be paused. 

15 51. A state machine as recited in claim 50, wherein either of the application 
manager or the application can initiate the transistion from said active state to said 
paused state. 

52. A state machine as recited in claim 47, wherein only the application manager 
20 initiates the transition from said paused state to said active state by starting the 

application. 

53. A state machine as recited in claim 47, wherein the states of said state 
machine together form an application lifecycle. 

25 

54. A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 

a computer-readable medium storing computer-readable instructions thereon, 
the computer-readable instructions including: 
30 instructions for loading the application such that the application enters a 

loaded state; 

instructions for initializing the application when the application is in the 
loaded state such that the application enters a paused state; 
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instructions for starting execution of the application when the application is in 
the paused state such that the application enters an active state; and 

instructions for terminating the execution of the application when the 
application is in the loaded state, the paused state, or the active state such that the 
application enters a destroyed state. 

55. The computer program product as recited in claim 54, further comprising: 
instructions for pausing the application when the application is in the active 

state such that the application enters the paused state. 

56. The computer program product as recited in claim 54, wherein the instructions 
for starting execution of the application when the application is in the paused state 
cannot be called by the apphcation. 



15 57. The computer program product as recited in claim 54, wherein the instructions 
for starting execution of the application when the application is in the paused state can 
only be called by a process that is extemal to the application. 

58. The computer program product as recited in claim 55, wherein the instructions 
20 for pausing the execution of the application when the application is in the active state 
can be called by the application or a process extemal to the application. 



59. The computer program product as recited in claim 54, wherein the instructions 
for terminating the application can be executed by the application or a process 
25 extemal to the application. 



60. A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 

a computer-readable medium storing computer-readable instructions thereon, 
30 the computer-readable instructions including: 

instructions for initializing an application such that the application enters a 
paused state; 
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instructions for starting execution of the application such that the application 
enters an active state; 

instructions for pausing the execution of the application such that the 
application enters the paused state; and 
5 instructions for terminating the application such that the application enters a 

destroyed state. 



61. A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 
10 a computer-readable medium storing computer-readable instructions thereon, 

the computer-readable instmctions including: 

instructions for starting execution of the application such that the application 
enters an active state; 

instructions for pausing the execution of the application such that the 
15 application enters the paused state; 

instructions for conditionally terminating the execution of the application such 
that the application enters a destroyed state when a predetermined condition is 
satisfied; and 

instructions for unconditionally terminating the execution of the application 
20 such that the application enters the destroyed state when the predetermined condition 
is not satisfied. 



62. The computer program product as recited in claim 61, wherein the 
predetermined condition is a signal received from the appUcation. 

25 

63. The computer program product as recited in claim 61, wherein the 
predetermined condition is an absence of a signal received from the application within 
a specified period of time. 



30 64. The computer program product as recited in claim 6 1 , further comprising: 
instructions for ignoring a state change exception raised by the application 
when the predetermined condition is not satisfied, the state change exception 
indicating that the application does not want to terminate. 
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65. A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 

a computer-readable medium storing computer-readable instructions thereon, 
the computer-readable instructions including: 
5 instructions for starting execution of the application such that the application 

enters an active state; 

instructions for pausing the execution of the application such that the 
application enters the paused state; 

instructions for terminating the application such that the application enters a 
10 destroyed state; and 

an interface including a set of instructions that enable a process other than the 
application to initiate execution of the instructions for starting execution of the 
application, the instructions for pausing the execution of the appHcation, and the 
instructions for terminating the application. 

15 

66, The computer program product as recited in claim 65, wherein the interface 
comprises a stub adapted for calling the instructions for terminating the application, 
the stub being capable of accepting a parameter indicating that termination of the 
application is unconditional when the parameter is in a first state and conditional 

20 when the parameter is in a second state. 



67, A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 

a computer-readable medium storing computer-readable instructions thereon, 
25 the computer-readable instructions including: 

instructions for communicating that the application has decided to terminate 
and has entered a destroyed state from a loaded state, a paused state, or an active state; 
and 

instructions for communicating that the application has decided to pause its 
30 execution and has entered the paused state fi-om the active state. 



68. The computer program product as recited in claim 67, further comprising: 
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instructions for communicating that the application wishes to resume 
execution and enter the active state from the paused state. 



69. The computer program product as recited in claim 67, further comprising: 

5 instructions for obtaining information associated with a runtime environment 

of the application. 

70. The computer program product as recited in claim 67, further comprising: 
an interface including a set of instructions that enable the application to 

10 initiate execution of the instructions for communicating that the application has 

decided to terminate and the instructions for communicating that the application has 
decided to pause its execution. 

71 . The computer program product as recited in claim 68, further comprising: 
15 an interface including a set of instructions that enable the application to 

initiate execution of the instructions for communicating that the application has 
decided to terminate, the instructions for communicating that the application has 
decided to pause its execution, and the instructions for communicating that the 
application wishes to resume execution and enter the active state from the paused 
20 state. 

72. A computer program product for managing execution of an application 
according to an application lifecycle, the computer program product comprising: 

a computer-readable medium storing computer-readable instructions thereon, 
25 the computer-readable instructions including: 

instructions for starting execution of the application such that the application 
enters an active state, wherein the instructions for starting execution of the application 
cannot be called by the application; 

instructions for pausing the execution of the application such that the 
30 application enters a paused state; and 

instructions for communicating that the application wishes to resume 
execution and enter the active state from the paused state. 
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73. The computer program product as recited in claim 72, further comprising: 

instructions for communicating that the application has decided to pause its 
execution and has entered the paused state from the active state. 

5 74. The computer program product as recited in claim 72, further comprising: 

instructions for terminating the application such that the application enters a 
destroyed state. 

75. The computer program product as recited in claim 74, further comprising: 
10 instructions for communicating that the application has decided to terminate 

and has entered the destroyed state. 
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